REMARKS 



Claims 1, 2, and 4-21 are pending. 
Claims 1, 2, and 4-21 stand rejected. 

Claims 1, 14, 20, and 21 have been amended. Claim 2 has been cancelled. 
Claims 22 through 29 have been added. 

The amendments to claims 1, 14, 20, and 21 are for clarification purposes and not related 
to patentability. 

Claim Objections - 37 CFR 1.75(e) 

Claim 2 is objected to under 37 CFR 1.75(c) as being of improper dependent form for 
failing to further limit the subject matter of a previous claim. Claim 2 has been cancelled and 
rewritten as independent claim 22. 

Applicants respectfully request withdrawal of the rejection. 

Claim Rejections - 35 U.S.C. § 103 

Claims 1, 2, and 4-21 stand rejected under 35 U.S.C. §103 as being unpatentable over 
U.S. Patent No. 6,587,827 issued to Henig et al. (referred to herein as "Henig'') in view of Bright 
et al., U.S. Patent AppHcation PubUcation No. US-2002/0013831 (referred to herein as "Brighr). 
Applicants respectfully traverse the rejection. 

The Examiner stated that Henig teaches that "the system maintains a database of all 
orders and forwards them to the specified supplier (splitting the order request into multiple 
processed order requests wherein each processed order request includes at least one of the 
items." The Examiner also stated that Henig teaches that "Once a preferred supplier is selected, 
the order is forwarded to that particular supplier and the transaction is processed by the supplier 
system (transmission of the processed order request to the ORMS of the fulfilhnent partner) 
[Figure 4]" The Examiner also stated that "the supplier (fulfillment partner) ships the product to 
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the customer and creates a confirmation event (receiving from the ORMSs of the selected 
fulfillment partners ORMS data associated with the processed order request transmitted to the 
ORMS of the fiilfillment partner," 

Regarding Bright, the Examiner stated that Bright teaches that "Electronic Sales Orders 
(ESO) made by a customer are split into multiple requests if there are multiple line items to be 
supphed by different delivery plants [Para. 17]. Primarily, the ESO is split based upon the 
evaluation of third party availability to fill an order, but the order can also be split according to a 
set of business rules [Para. 18]." 

Applicants appreciate the Examiner's work. However, AppHcants respectfully submit 
that the Examiner has misinterpreted and misapplied the teachings of Henis and Bright with 
respect to the present invention. 

Specifically, Applicants, in the following remarks and in accordance with Applicants' 
analysis of Henig and Bright, will demonstrate that (1) the chent of Henig determines whether 
more than one preferred supplier is needed as opposed to an "order request servicing system . . . 
processing the received order request into multiple processed order requests", (2) the server of 
Henig does not split any orders into multiple processed order requests, (3) since the server of 
Henig does not perform such a split, Henig does not teach or suggest "receiving from each of the 
ORMSs of the selected fulfilhnent partners ORMS data associated with the processed order 
request transmitted to the ORMS of the fulfillment partners and integrating the received ORMS 
data from the ORMSs of the fulfilhnent partners", (4) each ESO pre-processor of Bright is 
utilized by a supplier, (5) Bright teaches splitting an ESO into multiple requests for the same 
supplier having multiple delivery plants as opposed to processing a received request into 
multiple processed order requests and selecting fiilfilhnent partners for each of the processed 
order requests, (6) the "business" rules of Bright relate to how a supplier manages a request and 
not to "selecting fulfillment partners in accordance with business relationship rules and business 
relationship data", and (7) the differences between the combination of Henig and Bright and the 
present invention are not merely providing an automatic means to replace a manual activity, thus, 
rendering In re Venner inapplicable. 
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Henig and Bright Discussion 

Henig teaches that "For each customer order received, the cHent 10 determines a 
preferred suppUer 14 for the product ordered (block 40)." Henig, col. 5, his. 51-54 (emphasis 
added), Henig further teaches that "It should also be appreciated that a customer order may be 
for a large amount of product that may not be available at one supplier, or may specify several 
different shipping destinations that may not be convenient to a single supplier. In either event, 
there may be more than one preferred supplier determined to accommodate the availability 
constraints or the shipping destinations requested." Id., col. 1, hi. 64 through col. 2, In. 3. Thus, 
clearly "the cUent 10" and not a server "determines a preferred supplier 14 for the product 
ordered." Id., col. 5, his. 51-54. 

Not only does the client determine the preferred supplier . 

[a]fter the preferred suppUer 14 is determined, the client 10 next validates 
the information from the customer order by checking the validity of such 
information as the vendor number and/or the part number (block 42). The client 
10 then assigns a unique purchase order number (block 44), and creates an order 
event with all the information from the customer order and the assigned purchase 
order number (block 46)." Id., col 6, his. 4-1 1 (emphasis added). 

Henig also discusses the role of the server. More specifically, 

FIG. 4 shows the steps for the subroutine which defines how the server 12 
routes an order event to the preferred supplier 14. The server 12 first monitors the 
client 1 0 for an order event (block 48). . . . The server 1 2 obtains the order event 
from the client 10 if there is an order event available (block 50). The server 12 
next vaUdates the order event (block 52), for example, by checking to see if there 
is any empty field and/or incorrect types of data used in the field. ... the server 12 
directs the order event to the preferred supplier 14 if there is a supplier 14 (block 
60). ... If the supplier 14 is not found, the server 12 sends a rejection event to the 
cUent 10 (block 58). Id., col. 6, his. 16-18, 28-31, and 34-35 (emphasis added). 

The abstract of Henig summarizes the above teachings: 

The method includes the the client creating an order event with a preferred 
supplier, the server routing the order event to the preferred supplier, the server 
monitoring status of the order event from the preferred supplier, the preferred 
supplier processing the order event, and the server periodically synchronizing 
inventory between the cUent and all suppliers." Id., Abstract (emphasis added). 
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Thus, the server of Henis: does not split any orders into multiple processed order requests. 



Regarding communication to the client, Henig teaches that, 

[f|or an order event v^ith a rejected status, the server 12 sends a rejection 
event to the client 10 (block 88). ... On the other hand, the server 12 sends a 
confirmation event to the client 10 (block 94) if the order event has been closed 
by the suppUer 14. Id, col. 6, hs. 61-67 (emphasis added). 

Thus, the communication from the server relates to one order event, as received by the 
server from one supplier. 

Bright teaches that each ESO pre-processor is utilized by one supplier. Bright teaches 
that [a]ccordingly, in the preferred embodiment of the invention, a supplier enabled for 
electronic commerce using the SAP AG Corporation sales and distribution modules for order 
fulfillment can use the Electronic Sales Order (ESO) pre-processor." Bright, para. 16. Thus, 
ESO pre-processor does not split orders among multiple suppliers. 

Bright also teaches that "the ESO pre-processor splits the ESO into multiple requests if 
there are muUiple line items supplied by different delivery plants that are not configured to share 
the same sales area in SAP." Id., para. 17. Thus, Bright teaches that the suppher receives one 
request, and the ESO pre-processor system can spUt the request into multiple requests if the line 
items will be supplied by different delivery plants. This interpretation is supported by Bright 's 
next statement that "Without this fimction, the supp lier would have to perform this activity 
manually." Id. Thus, the split requests are indeed for the same supplier and not spUt among 
multiple suppUers. See also, Bright paras. 22, 1 16, and 123. (Applicants respectfiiUy submit that 
the "third party availability check" in para. 18 refers to the use of third party software to check 
availability. Specifically, Bright teaches that "a supplier enabled for electronic commerce using 
the SAP AG Corporation sales and distribution modules for order fiilfiUment can use the 
Electronic Sales Order (ESO) pre-processor (e.g. the order interceptor) to perform an 
asvnchronous availability check (using, for example, the PROFIT Available to Promise (ATP) 
by International Business Machine Corp., or any other suitable third party software packag eV" 
M, para. 16.) 
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Bright does teach about business rules. However, Bright 's " business rules [allowl a 
su pplier to configure how a request is managed . For example, a new sales order request fi:om a 
low-tiered customer can be configured for manual service prior to posting." Id. para. 18 
(emphasis added). Thus, the business rules taught by Bright relate to how a supplier configures a 
request and not to how fulfilhnent partners are selected. 

Henig, Bright^ and the Present Invention 

Claim 1 

In light of the above discussion, the combination of Henig and Bright teaches that (1) 
"the client of Henig determines whether more than one preferred supplier is needed", (2) an 
order is provided to a supplier, and (3) the suppUer can split the order into multiple requests. hL 
contrast to the combined teachings of Henig and Bright, the invention of claim 1 recites a 
"method for utilizing the order request servicing svstem comprising: receiving with the order 
request servicing system an order request fi-om a client svstem . processing the received order 
request into multiple processed order requests , and selecting fulfilhnent partners for each of the 
processed order requests." Present Application, claim 1 (emphasis added). Furthermore, 
because neither Henig nor Bright, alone or in combination, teach "selecting fiilfilhnent partners 
for each of the processed order requests", neither Henig nor Bright can possibly teach "for each 
of the processed order requests, transmitting the processed order request to the ORMS of the 
selected fiilfilhnent partner." Id. 

Henig does teach that a server sends to a client a "rejection event" or a "confirmation 
event" to a client. However, both of these communication events relate to "an order event" fi-om 
one supplier. In contrast to the present invention of claim 1, neither Henig nor Bright, alone or 
in combination, teach "receiving fi-om each of the ORMSs of the selected fiilfilhnent partners 
ORMS data associated with the processed order request transmitted to the ORMS of the 
fiilfilhnent partners and integrating the received ORMS data fi-om the ORMSs of the fiilfilhnent 
partners." Present Application, claim 1. The Examiner stated that Henig teaches that "the 
supplier (fiilfillment partner) ships the product to the customer and creates a confirmation event 
(receiving from the ORMSs of the selected fiilfilhnent partners ORMS data associated with the 
processed order request transmitted to the ORMS of the fulfillment partner." However, the 
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confirmation event relates to one supplier not to multiple fulfillment partners as recited in claim 
1 . Furthermore, neither the Examiner nor Henig and Bright mention "integrating the received 
ORMS data fi-om the ORMSs of the fiilfilhnent partners." Present Application, claim 1. 

Claim 14 

For reasons similar to those of claim 1, neither Henig nor Bright, alone or in combination, 
teach or suggest: 

a processing engine to: 

process the order request into multiple processed order requests : 

select fiilfilhnent partners for each of the processed order requests 
using the business relationship information; 

for each of the processed order requests , transmit the processed 
order request to the ORMS of the selected fiilfiUment partner; 

receive fi-om each of the ORMSs of the selected fiilfiUment 
partners ORMS data associated with the processed order request 
transmitted to the ORMS of the fiilfiUment partners; and 

integrate the received ORMS data fi-om the ORMSs of the 
fiilfilhnent partners . 

Present Application, Claim 14 (emphasis added). 

Furthermore, regarding business rules, the Examiner states that Bright "does hot 
expUcitly disclose that the business rules are used to designate a particular suppUer. Essentially 
however, Bright et al. teaches ah automated pre-processing order system that filters a customer's 
order through a business rules database - the rules stored could be of any nature, including 
preferences for selecting particular suppliers - before sending it to the order management 
system." Applicants agree with the Examiner that Bright does not teach "a first order request 
servicing system having an interface to receive an order request from a client svstem , having a 
memory to store business relationship information relating a client and the fiilfilhnent partners " 
and "select fiilfilhnent partners for each of the processed order requests using the business 
relationship information ." Bright specifically teaches that, 

the pre-processor provides a robust set of business rules that allows a 
supplier to configure how a request is managed . For example, a new sales order 
request from a low-tiered customer can be configured for manual service prior to 
posting. The same request from a high-tiered customer can be configured for 
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manual review only under certain conditions , such as if the requester falls under 
minimum order quantity levels, while the same request from another customer in 
the same condition could be configured for automatic routing . 

Applicants respectfully submit that only impermissible hindsight could be used to 
construe Bright 's exphcit teachings regarding business rules to suggest "a memory to store 
business relationship information relating a client and the fulfilhnent partners " and "select 
fiilfillment partners for each of the processed order requests using the business relationship 
information " as recited by claim 14. 

Claim 20 

For reasons similar to those of claim 1, neither Henig nor Bright, alone or in combination, 
teach or suggest: 

A transaction processing system having an order request servicing system 
for routing order requests to multiple order request management systems 
("ORMSs") of fulfillment partners and integrating respective ORMS data from 
ORMSs of each fulfillment partner, the transaction processing system comprising: 

means for receiving an order request from a client system ; 

means for processing the order request into multiple processed order 
requests ; 

means for selecting fulfillment partners for each of the processed order 
requests ; 

means for transmitting the processed order request to the ORMS of the 
selected fulfillment partner ; 

means for receiving from each of the ORMSs of the selected fulfillment 
partners ORMS data associated with the processed order request 
transmitted to the ORMS of the fulfilhnent partners; and 

means for integrating the received ORMS data from the ORMSs of the 
fulfillment partners . 

Present Application, Claim 20 (emphasis added). 

Claim 21 

For reasons similar to those of claim 1, neither Henig nor Bright, alone or in combination, 
teach or suggest: 

A program storage device readable by a machine, tangibly embodying a 
program of instructions executable by the machine to perform a method for 
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utilizing an order request servicing system for routing order requests to multiple 
order request management systems ("ORMSs") of fulfillment partners and 
integrating respective ORMS data from ORMSs of each fulfillment partner, the 
method for utilizing an order request servicing system comprising: 

receiving with the order request servicing system an order request from a 
client system; 

processing the order request into multiple processed order requests ; 

selecting fulfillment partners for each of the processed order requests : 

for each of the processed order requests, transmitting the processed order 
request to the ORMS of the selected fulfilhnent partner; 

receiving from each of the ORMSs of the selected fulfillment partners 
ORMS data associated with the processed order request 
transmitted to the ORMS of the fiilfiUment partners ; and 

integrating the received ORMS data from the ORMSs of the fulfillment 
partners . 

Present Application, Claim 21 (emphasis added). 

Claim 22 

For reasons similar to those of claim 1, neither Henig nor Bright, alone or in combination, 
or suggest: 

an order request servicing system for routing order requests to multiple 
order request management systems ("ORMSs") of fulfillment partners and 
integrating respective ORMS data from ORMSs of each fulfilhnent partner, 
wherein the order request servicing system includes components to: 

receive an order request from a client system in electronic communication 
with the order request servicing system; 

process the received order request into multiple processed order requests ; 

select fulfilhnent partners for each of the processed order requests ; 

for each of the processed order requests, transmit the processed order 
request to the ORMS of the selected fulfillment partner ; 

receive from each of the ORMSs of the selected fulfillment partners 
ORMS data associated with the processed order request 
transmitted to the ORMS of the fulfilhnent partners; and 

integrate the received ORMS data from the ORMSs of the fiilfilhnent 
partners . 

Present Application, Claim 22 (emphasis added). 
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Regarding In re Venner , the Examiner stated that "simply automating the step of 
selecting a preferred supplier based upon known business rules gives you just what you would 
expect from the manual step as shown in Henig'' Even assuming arguendo that In re Venner is 
valid law, as discussed above the present invention differs in many ways from the teachings of 
Henig, alone or in combination with Bright, For example, the client system of Henig determines 
whether more than one preferred supplier is needed. This is significantly different than, for 
example, "a first order request servicing system having an interface to receive an order request 
from a client system, having a memory to store business relationship information relating a client 
and the fiilfilhnent partners, and having a processing engine to: process the order request into 
multiple processed order requests [and] select fiilfillment partners for each of the processed order 
requests using the business relationship information" as recited in claim 14. Additionally, as 
discussed above, many other elements of each independent claim differ from Henig, alone or in 
combination with Bright, in a nonobvious and non-automated versus manual way. The other 
independent claims can be similarly presented. 

Dependent Claims 

Applicants respectfiiUy submit that the Examiner did not address all the dependent claims 
in the Office Action. For example, Applicants did not locate any reasons for rejecting claims 9 
and 18 which relate to inter alia an "order servicing organization" with interconnected order 
servicing systems. Applicants respectfully submit that neither Henig nor Bright, alone or in 
combination, teach or suggest the order servicing organizations of claims 9 and 18. Henig does 
refer to a "hub" concept in column 3 and Figure 1 . However, the Henig "hub" does not include 
the order request servicing systems as recited in claims 9 and 18. 

Additionally, Applicants respectfiilly submit that all dependent claims are allowable for 
at least the same reasons as the independent claim from they directly or indirectly depend. 
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CONCLUSION 

In view of the amendments and remarks set forth herein, the appUcation is believed to be 
in condition for allowance and a notice to that effect is solicited. Nonetheless, should any issues 
remain. Applicants' representative below requests a telephonic interview prior to issuance of any 
final rejection. 



I hereby certify that this correspondence is being deposited with 
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addressed to: Mail Stop Fee Amendment, Commissioner for 
Patents, P.O. Box 1450, Alexandria, VA 22313-1450, on May 26, 
2004. 
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